-- *******************************************************************
-- CISCO-LWAPP-MOBILITY-MIB.my
-- June 2006, Bharat Biswal-- Copyright (c) 2005-2006 by Cisco Systems, Inc.
-- All rights reserved.
-- *******************************************************************CISCO-LWAPP-MOBILITY-MIB DEFINITIONS::=BEGINIMPORTSMODULE-IDENTITY,OBJECT-TYPE,NOTIFICATION-TYPE,Unsigned32,Integer32FROM SNMPv2-SMI
MODULE-COMPLIANCE,
OBJECT-GROUP,NOTIFICATION-GROUPFROM SNMPv2-CONF
DisplayString,TruthValue,RowStatusFROM SNMPv2-TC
InetAddressType,InetAddressFROM INET-ADDRESS-MIB
ciscoMgmt
FROM CISCO-SMI;-- ********************************************************************
-- * MODULE IDENTITY
-- ********************************************************************ciscoLwappMobilityMIB MODULE-IDENTITYLAST-UPDATED"200607190000Z"ORGANIZATION"Cisco Systems Inc."CONTACT-INFO"Cisco Systems,
Customer Service
Postal: 170 West Tasman Drive
San Jose, CA 95134
USA
Tel: +1 800 553-NETS
Email: cs-snmp@cisco.com"DESCRIPTION"This MIB is intended to be implemented on all those
devices operating as Central Controllers (CC) that
terminate the Light Weight Access Point Protocol
tunnel from Light-weight LWAPP Access Points.
This MIB provides configuration and status information
about the 802.11 WLAN mobility.
The relationship between CC and the LWAPP APs
can be depicted as follows:
+......+ +......+ +......+ +......+
+ + + + + + + +
+ CC + + CC + + CC + + CC +
+ + + + + + + +
+......+ +......+ +......+ +......+
.. . . .
.. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+
+......+
+ + + + + + + + +
+
+ AP + + AP + + AP + + AP + + AP
+
+ + + + + + + + +
+
+......+ +......+ +......+ +......+
+......+
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+
+......+
+ + + + + + + + +
+
+ MN + + MN + + MN + + MN + + MN
+
+ + + + + + + + +
+
+......+ +......+ +......+ +......+
+......+
The LWAPP tunnel exists between the controller and
the APs. The MNs communicate with the APs through
the protocol defined by the 802.11 standard.
LWAPP APs, upon bootup, discover and join one of the
controllers and the controller pushes the configuration,
that includes the WLAN parameters, to the LWAPP APs.
The APs then encapsulate all the 802.11 frames from
wireless clients inside LWAPP frames and forward
the LWAPP frames to the controller.
GLOSSARY
Access Point ( AP )
An entity that contains an 802.11 medium access
control ( MAC ) and physical layer ( PHY ) interface
and provides access to the distribution services via
the wireless medium for associated clients.
LWAPP APs encapsulate all the 802.11 frames in
LWAPP frames and sends it to the controller to which
it is logically connected.
Basic Service Set Identifier (BSSID)
The identifier for the service set comprising of
all the 802.11 stations under the control of
one coordinating Access Point. This identifier
happens to be the MAC address of the dot11 radio
interface of the Access Point. The wireless
clients that associate with the Access Point
get the wired uplink through this particular
dot11 interface.
Central Controller ( CC )
The central entity that terminates the LWAPP protocol
tunnel from the LWAPP APs. Throughout this MIB,
this entity also referred to as 'controller'.
Light Weight Access Point Protocol ( LWAPP )
This is a generic protocol that defines the
communication between the Access Points and the
Central Controller.
Mobile Node ( MN )
A roaming 802.11 wireless device in a wireless
network associated with an access point.
Mobility
Concept by which a Mobile Node can roam from one
Access Point to another Access Point, across multiple
Central Controllers, without need for repeated
authentication.
Mobility Group
A set of Central Controllers which exchange Mobile
Node's authentication information, so that the Mobile
Node upon roaming need not re-authenticate.
Mobility Anchor
When a Central Controller in the Mobility Group is
designated as Mobility Anchor, then all the Mobile
Node's traffic is tunnelled to it by other
Controllers in the Mobility Group.
Guest Tunneling (GT)
The concept of designating a Central Controller in
the Mobility Group as Mobility Anchor, so that all
the Mobile Node's traffic is tunnelled to it by other
Controllers in the Mobility Group.
Station Management (SMT)
This term refers to the internal management of the
802.11 protocol operations by the AP to work
cooperatively with the other APs and 802.11
devices in the network.
Ethernet over Internet Protocol (EoIP)
Ethernet over IP (EoIP) is a protocol that creates
an Ethernet tunnel between two routers on top of an
IP connection. The EoIP interface appears as an
Ethernet interface.
Reverse path filtering (RPF)
Reverse path filtering (RPF) is a feature provided
by most modern Internet Protocol routers, which may
be used to reduce the risk of customers attacking
other internet hosts. One of the problems network
service providers face today is hackers generating
packets with fake source IP addresses, a technique
known as spoofing. This is often done in order to
initiate a denial-of-service attack against another
internet host or network.
Since the source IP addresses of the incoming packets
change, often randomly, and for every packet, the
target of such an attack can't easily filter out the
attacking packets. However, the source of the attack,
i.e. the network service provider of the attacking
host, has a simple way to stop such packets from ever
leaving its network. A router always knows which
networks are reachable via any of its interfaces.
By checking the source IP address of all packets
coming in via an interface against the networks known
to be behind that interface, the router can simply
drop packets that aren't supposed to come from there.
Hence, reverse path filtering filters packets
according to the 'reverse path' to their source
address. If the path back to the source address
does not match the path the packet is coming from,
it is dropped.
REFERENCE
[1] Part 11 Wireless LAN Medium Access Control ( MAC )
and Physical Layer ( PHY ) Specifications.
[2] Draft-obara-capwap-lwapp-00.txt, IETF Light
Weight Access Point Protocol. "REVISION"200607190000Z"DESCRIPTION"Initial version of this MIB module."::={ ciscoMgmt 576}ciscoLwappMobilityMIBNotifs OBJECTIDENTIFIER::={ ciscoLwappMobilityMIB 0}ciscoLwappMobilityMIBObjects OBJECTIDENTIFIER::={ ciscoLwappMobilityMIB 1}
ciscoLwappMobilityMIBConform OBJECTIDENTIFIER::={ ciscoLwappMobilityMIB 2}-- *******************************************************************
-- Per WLAN, anchors table
-- *******************************************************************cLMobilityAnchorTable OBJECT-TYPESYNTAXSEQUENCEOF CLMobilityAnchorEntry
MAX-ACCESSnot-accessibleSTATUScurrentDESCRIPTION"This table represents the information about the
802.11 LWAPP Mobility Anchors on individual WLANs.
+...............+
+ +
+ ROUTER +
+ 10.16.1.1 +
+...............+
..
. .
. .
. .
. .
. .
10.16.109.112 10.16.105.39
+......+ <<-------->> +......+
+ + [3]CC2 tunnels + +
+ CC1 + MN1's traffic + CC2 +
+ + to Anchor CC1 + +
+......+ using EoIP +......+
. .
. Anchor Foreign .
. .
+......+ +......+
+ + + +
+ AP1 + + AP2 +
+ + + +
+......+ +......+
'typhoon' . ^ 'typhoon'
. |
. [2] associates |
. with AP2/CC2 |
. |
+......+ [1] +......+
+ + moves to region + +
+ MN1 + ---------->>> + MN1 +
+ + serviced by AP2 + +
+......+ +......+
10.16.109.199 10.16.109.199
In the above diagram, Central Controllers CC1 and CC2 have
been configure in a Mobility Group.
Currently the Mobile Node 'MN1' obtains its IP from the
Central Controller 'CC1' with which it first associates
via WLAN 'typhoon' through Access Point 'AP1'. 'CC1'
obtains DHCP address, say 10.16.109.199 for client 'MN1'.
Now the client 'MN1' is identified by 10.16.109.199 for
furthure communication with the network and the
communication happens via 'CC1'.
Since, 'CC1' and 'CC2' are in same mobility group, 'CC1'
sends the authentication block of 'MN1' to 'CC2'.
Central Controller 'CC2' has an associated Access Point
'AP2' which beams WLAN 'typhoon' and uses 10.16.105.0 /
255.255.255.0 subnet instead.
Next, the Mobile Node 'MN1' moves out of range of 'AP1'
and gets in to proximity with 'AP2' and continues to use
WLAN 'typhoon'. 'CC2' locally authenticates 'MN1' against
authentication block shared from 'CC1'. 'CC2' forwards all
traffic from 'MN1' to router. This is called WLAN mobility.
But hold on, 'CC2' uses 10.16.105.0 / 255.255.255.0 subnet
for WLAN 'typhoon'. So we have two problems here :
a> Traffic of 10.16.109.0 / 255.255.255.0 subnet has to be
accessible from 10.16.105.0 / 255.255.255.0 subnet.
b> Unneccessary overloading of 10.16.105.0 / 255.255.255.0
subnet by traffic from 10.16.109.0 / 255.255.255.0 subnet.
How do we address these issues ??
If an EoIP tunnel can be established between 'CC1' and 'CC2'
and 'CC1' sends all traffic bound to 'MN1', 10.16.109.199,
on this tunnel to 'CC2', which in turn forwards it to 'MN1',
then, above two subnet-problems are resolved. This is called
Mobility Anchoring. 'CC1' is the Mobility Anchor and 'CC2' is
the 'Foreign' for WLAN 'typhoon'.
As per the configuration, user creates a MobilityAnchor entry
in 'CC2' for WLAN 'typhoon' with IP address as 'CC1', i.e.
10.16.109.112. So, when 'MN1' connects to WLAN 'typhoon' via
'AP2', then 'CC2' establishes EoIP tunnel with 10.16.109.112
and forwards the packets to 'MN1'.
Given the above example, the cLMobilityAnchorEntry on 'CC2'
looks like :
------------------------------------------------------------------
| MIB - ATTRIBUTES | ROW#1 | ROW#2 |
------------------------------------------------------------------
| cLMobilityAnchorWlanSsid | typhoon | |
------------------------------------------------------------------
| cLMobilityAnchorSwitchIPAddress | 10.16.109.112 | |
------------------------------------------------------------------
| cLMobilityAnchorStatus | up(4) | |
------------------------------------------------------------------
| cLMobilityAnchorRowStatus | active(1) | |
------------------------------------------------------------------
This feature has advantages for both security and load
balancing. It can be used to restrict a WLAN to a single
subnet, regardless of the MN's entry point into the network.
A 'public' or guest WLAN can thus be accessed throughout an
enterprise, but still is restricted to a specific subnet.
It can also be used to provide some geographic load balancing,
since the WLANs can represent a particular section of a
building (ie., engineering, marketing). Those groups can be
'anchored' on a particular subnet/switch rather than on the
CC of first occurrence (ie., the switch controlling the APs
by the front door).
"::={ ciscoLwappMobilityMIBObjects 1}cLMobilityAnchorEntry OBJECT-TYPESYNTAX CLMobilityAnchorEntry
MAX-ACCESSnot-accessibleSTATUScurrentDESCRIPTION"Each entry in this table provides information about
one 802.11 LWAPP Mobility Anchor configured on a WLAN
on this controller."INDEX{
cLMobilityAnchorWlanSsid,
cLMobilityAnchorSwitchAddressType,
cLMobilityAnchorSwitchAddress
}::={ cLMobilityAnchorTable 1}
CLMobilityAnchorEntry ::=SEQUENCE{
cLMobilityAnchorWlanSsid DisplayString,
cLMobilityAnchorSwitchAddressType InetAddressType,
cLMobilityAnchorSwitchAddress InetAddress,
cLMobilityAnchorStatus BITS,
cLMobilityAnchorRowStatus RowStatus}cLMobilityAnchorWlanSsid OBJECT-TYPESYNTAXDisplayString(SIZE(1..32))MAX-ACCESSnot-accessibleSTATUScurrent
DESCRIPTION"Local wlan-ssid to connect to Guest/Anchor switch"::={ cLMobilityAnchorEntry 1}cLMobilityAnchorSwitchAddressType OBJECT-TYPESYNTAXInetAddressTypeMAX-ACCESSnot-accessibleSTATUScurrentDESCRIPTION"Guest/Anchor switch Address type."::={ cLMobilityAnchorEntry 2}cLMobilityAnchorSwitchAddress OBJECT-TYPESYNTAXInetAddressMAX-ACCESSnot-accessibleSTATUScurrentDESCRIPTION"Guest/Anchor switch Address.
The IP Address is limited to IPv4 and IPv6."::={ cLMobilityAnchorEntry 3}cLMobilityAnchorStatus OBJECT-TYPESYNTAXBITS{controlpath(0),datapath(1)}MAX-ACCESSread-onlySTATUScurrentDESCRIPTION"Operational and Connectivity status of the
Mobility Anchor.
controlpath:
When bit is '0', this means successive
ICMP pings to the anchor have failed.
When is '1', this means anchor is
reachable and responding to ICMP pings.
datapath:
When bit is '0', this means successive
EoIP pings to the anchor have failed.
When bit is '1', this means anchor is
reachable and responding to EoIP pings.
"::={ cLMobilityAnchorEntry 4}cLMobilityAnchorRowStatus OBJECT-TYPESYNTAXRowStatusMAX-ACCESSread-createSTATUScurrentDESCRIPTION"Row Status"::={ cLMobilityAnchorEntry 5}-- ********************************************************************
-- * Global Dot11 Mobility Anchor Configuration
-- ********************************************************************cLMobilityAnchorGlobalDot11Config OBJECTIDENTIFIER::={ ciscoLwappMobilityMIBObjects 2}
cLMobilityAnchorGroupKeepAliveNumber OBJECT-TYPESYNTAXInteger32(3..20)MAX-ACCESSread-writeSTATUScurrentDESCRIPTION"This parameter determines how many successive
ping attempts to the anchor should fail before
the anchor is declared DOWN."DEFVAL{3}::={ cLMobilityAnchorGlobalDot11Config 1}cLMobilityAnchorGroupKeepAliveInterval OBJECT-TYPESYNTAXInteger32(1..30)MAX-ACCESSread-write
STATUScurrentDESCRIPTION"This parameter determines the time interval
(in seconds) between two consecutive ping attempts
to an anchor."DEFVAL{10}::={ cLMobilityAnchorGlobalDot11Config 2}cLMobilityAnchorSmtStatus OBJECT-TYPESYNTAXTruthValueMAX-ACCESSread-writeSTATUScurrentDESCRIPTION"This object allows user to enable or disable
Symmetric mobility tunneling for the controller.
The controller provides inter-subnet mobility
for clients roaming from one AP to another within
a Wireless LAN. This mobility is asymmetric in
nature where the client traffic to the wired
network is routed out directly via the 'foreign'
controller. See the diagram above. This mechanism
breaks when an upstream router has RPF enabled.
In this case the client traffic will be dropped
at the router because the RPF check ensures that
the path back to the source address matches the
path the packet is coming from.
This attribute is aimed at addressing this issue.
It will allow enabling 'Symmetric Mobility
Tunneling' or 'Bi-directional Tunneling'
for mobile clients such that all the client
traffic is sent to the 'anchor' controller and
go successfully through RPF check.
When set to 'true', Symmetric Mobility Tunneling
will be enabled on the Controller on next reset.
When set to 'false', Symmetric Mobility Tunneling
will be disabled on the Controller on next reset.
After setting this attribute to the desired value,
user should reset the Controller for the change to
take effect.
"::={ cLMobilityAnchorGlobalDot11Config 3}
cLMobilityAnchorCurrentSmt OBJECT-TYPESYNTAXTruthValueMAX-ACCESSread-onlySTATUScurrentDESCRIPTION"This object represents the current state of
Symmetric mobility tunneling for the controller.
When value is 'true', this means Symmetric Mobility
Tunneling is currently enabled on the Controller.
When value is 'false', this means Symmetric Mobility
Tunneling is currently disabled on the Controller."::={ cLMobilityAnchorGlobalDot11Config 4}-- *******************************************************************
-- * DEFINITION OF OBJECTS ACCESSIBLE FOR NOTIFICATIONS ONLY
-- *******************************************************************cLMobilityTrapVariables OBJECTIDENTIFIER::={ ciscoLwappMobilityMIBObjects 3}
cLMobilityAnchorWlanId OBJECT-TYPESYNTAXUnsigned32MAX-ACCESSaccessible-for-notifySTATUScurrentDESCRIPTION"This object uniquely identifies one instance of
a WLAN on the controller."::={ cLMobilityTrapVariables 1}cLMobilityAnchorAddressType OBJECT-TYPESYNTAXInetAddressTypeMAX-ACCESSaccessible-for-notifySTATUScurrentDESCRIPTION"Guest/Anchor switch Address type."::={ cLMobilityTrapVariables 2}
cLMobilityAnchorAddress OBJECT-TYPESYNTAXInetAddressMAX-ACCESSaccessible-for-notifySTATUScurrentDESCRIPTION"Guest/Anchor switch Address.
The IP Address is limited to IPv4 and IPv6"::={ cLMobilityTrapVariables 3}-- *******************************************************************
-- * END OF - DEFINITION OF OBJECTS ACCESSIBLE FOR NOTIFICATIONS ONLY
-- *******************************************************************-- *******************************************************************
-- * NOTIFICATIONS
-- *******************************************************************ciscoLwappMobilityAnchorControlPathDown NOTIFICATION-TYPEOBJECTS{
cLMobilityAnchorAddressType,
cLMobilityAnchorAddress
}STATUScurrentDESCRIPTION"This trap will be declared by the Controller when,
successive ICMP ping attempts to the anchor fails
and the anchor is conclusively down.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor."::={ ciscoLwappMobilityMIBNotifs 1}ciscoLwappMobilityAnchorControlPathUp NOTIFICATION-TYPEOBJECTS{
cLMobilityAnchorAddressType,
cLMobilityAnchorAddress
}STATUScurrentDESCRIPTION"This trap will be declared by the Controller when,
ICMP ping to the anchor is restored and anchor is
conclusively up.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor."::={ ciscoLwappMobilityMIBNotifs 2}ciscoLwappMobilityAnchorDataPathDown NOTIFICATION-TYPEOBJECTS{
cLMobilityAnchorAddressType,
cLMobilityAnchorAddress
}STATUScurrentDESCRIPTION"This trap will be declared by the Controller when,
successive EoIP ping attempts to the anchor fails
and the anchor is conclusively down.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor."::={ ciscoLwappMobilityMIBNotifs 3}ciscoLwappMobilityAnchorDataPathUp NOTIFICATION-TYPEOBJECTS{
cLMobilityAnchorAddressType,
cLMobilityAnchorAddress
}STATUScurrentDESCRIPTION"This trap will be declared by the Controller when,
EoIP ping to the anchor is restored and anchor is
conclusively up.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor."::={ ciscoLwappMobilityMIBNotifs 4}ciscoLwappMobilityAllAnchorsOnWlanDown NOTIFICATION-TYPEOBJECTS{ cLMobilityAnchorWlanId }STATUScurrentDESCRIPTION"This trap will be declared by the Controller when,
successive EoIP ping attempts to all the anchors on
WLAN, denoted by cLMobilityAnchorWlanId, fails and
all the anchors are conclusively down."
::={ ciscoLwappMobilityMIBNotifs 5}ciscoLwappMobilityOneAnchorOnWlanUp NOTIFICATION-TYPEOBJECTS{ cLMobilityAnchorWlanId }STATUScurrentDESCRIPTION"This trap will be declared by the Controller when,
successive EoIP and UDP ping to atleast one anchor
on the WLAN, denoted by cLMobilityAnchorWlanId, is
restored and anchor is conclusively up."::={ ciscoLwappMobilityMIBNotifs 6}-- *******************************************************************
-- * END OF - NOTIFICATIONS
-- *******************************************************************-- *******************************************************************
-- * Compliance statements
-- *******************************************************************
ciscoLwappMobilityMIBCompliances OBJECTIDENTIFIER::={ ciscoLwappMobilityMIBConform 1}ciscoLwappMobilityMIBGroups OBJECTIDENTIFIER::={ ciscoLwappMobilityMIBConform 2}ciscoLwappMobilityMIBCompliance MODULE-COMPLIANCESTATUScurrentDESCRIPTION"The compliance statement for the SNMP entities that
implement the ciscoLwappMobilityMIB module."MODULE-- this moduleMANDATORY-GROUPS{
cLNplus1RedundancyRev01ConfigGroup,
cLNplus1RedundancyRev01StatusGroup,
cLNplus1RedundancyRev01NotifsGroup,
cLSymmetricTunnelingRev01ConfigGroup,
cLSymmetricTunnelingRev01StatusGroup
}::={ ciscoLwappMobilityMIBCompliances 1}-- *******************************************************************
-- * Units of conformance
-- *******************************************************************cLNplus1RedundancyRev01ConfigGroup OBJECT-GROUPOBJECTS{
cLMobilityAnchorGroupKeepAliveNumber,
cLMobilityAnchorGroupKeepAliveInterval
}STATUScurrentDESCRIPTION"This is a collection of objects which can
configured to control functional parameters
of Guest Tunneling N+1 Redundancy feature in
CISCO 4400 / 2006 series of WLAN controllers."::={ ciscoLwappMobilityMIBGroups 1}
cLNplus1RedundancyRev01StatusGroup OBJECT-GROUPOBJECTS{
cLMobilityAnchorStatus,
cLMobilityAnchorRowStatus,
cLMobilityAnchorWlanId,
cLMobilityAnchorAddressType,
cLMobilityAnchorAddress
}STATUScurrentDESCRIPTION"This collection of objects represents the information
about the general status attributes of Guest Tunneling
N+1 Redundancy in CISCO 4400 / 2006 series of WLAN
controllers."::={ ciscoLwappMobilityMIBGroups 2}cLNplus1RedundancyRev01NotifsGroup NOTIFICATION-GROUPNOTIFICATIONS{
ciscoLwappMobilityAnchorControlPathDown,
ciscoLwappMobilityAnchorControlPathUp,
ciscoLwappMobilityAnchorDataPathDown,
ciscoLwappMobilityAnchorDataPathUp,
ciscoLwappMobilityAllAnchorsOnWlanDown,
ciscoLwappMobilityOneAnchorOnWlanUp
}STATUScurrentDESCRIPTION"This is a collection of notifications about the
general functional behavior of Guest Tunneling
N+1 Redundancy in CISCO 4400 / 2006 series of
WLAN controllers."::={ ciscoLwappMobilityMIBGroups 3}cLSymmetricTunnelingRev01ConfigGroup OBJECT-GROUPOBJECTS{ cLMobilityAnchorSmtStatus }STATUScurrent
DESCRIPTION"This is a collection of objects which can be
configured to control functional parameters
of Symmetric Mobility Tunneling feature in
CISCO 4400 / 2006 series of WLAN controllers."::={ ciscoLwappMobilityMIBGroups 4}cLSymmetricTunnelingRev01StatusGroup OBJECT-GROUPOBJECTS{ cLMobilityAnchorCurrentSmt }STATUScurrentDESCRIPTION"This collection of objects represents the
information about the general status attributes
of Symmetric Mobility Tunneling feature in
CISCO 4400 / 2006 series of WLAN controllers."::={ ciscoLwappMobilityMIBGroups 5}END